1. Field of the Invention
The invention relates to network devices.
2. Description of the Related Art
One limitation of Fibre Channel (FC) is the practical number of domains or switches that can be present in a fabric. Another concern with FC is the amount of time required to reconfigure the fabric on removal or addition of a new switch. To address these points, a system and method as described in U.S. Pat. No. 7,707,309, entitled “Isolation Switch for Fibre Channel Fabrics in Storage Area Networks” was developed. In that design a switch is connected to hosts in the usual manner but is connected to an FC fabric using N_Port ID Virtualization (NPIV) ports, with one NPIV address for each connected host. The switch translated addresses between those provided to the host and those assigned using the NPIV process. U.S. Pat. No. 7,577,134, entitled “Port Expander for Fibre Channel Fabrics in Storage Area Networks” improved on the design of the '309 patent by passing the NPIV addresses directly to the connected hosts, removing the translation step.
Another concern in FC has been the relatively high cost of the host bus adapters (HBAs) and the switches, particularly as compared to the corresponding Ethernet network interface cards (NICs) and switches and routers. To that end a technology called Fibre Channel over Ethernet (FCoE) has been developed. Basically an FC packet is encapsulated in an Ethernet packet and transferred through a data center Ethernet network. In an FCoE environment, a host or Enode uses either a converged network adapter (CNA), which receives FC packets and encapsulates them itself, or an FCoE driver, which receives the FC packets, converts them to FCoE packets and then provides those to a normal NIC. The FCoE packets are provided to a Fibre Channel Forwarder (FCF), which is a device that is connected to both the Ethernet network and an FC fabric. The FCF receives FCoE packets, converts them to FC packets and then provides them to the FC fabric using an E_Port or fabric port. The FCF acts as a normal FC switch, performing fabric login operations and the like and consumes a domain. In the opposite direction, from storage device to host, the FCF receives the FC packets from the storage unit, converts them to FCoE packets and provides them to the Ethernet network, where they are delivered to the host. The FCoE subsystem of the host, either a CNA or a driver and NIC, convert the FCoE packets to FC packet data, which the host then processes. While this approach addresses a cost issue, it does nothing to address the number of switches problem of FC as each FCF consumes another domain.
One approach to address that concern has been the development of the FCoE to FC gateway, essentially the combination of an FCF and the above mentioned Port Expander. The FCoE to FC gateway connects to the FC fabric using NPIV ports, as discussed above. The FCF portion of the gateway terminates the FCoE network by providing a VF_Port. Internally the FC packets are obtained but then they are provided to the NPIV port for transmission through the FC fabric. The FC portion of the gateway behaves just as the NPIV port of the port expander, except that it is connected internally to an FCoE port rather than an F_Port. This addresses the domain count concern but still requires each FCoE packet to be routed through the Ethernet network to the specific FCoE to FC gateway, as only that one unit has the needed information to perform the necessary packet operations.
In a different area, the number of hosts used in a data center has been increasing dramatically, particularly with the advent of virtual machine (VM) usage. As each VM consumes a MAC address and usually an IP address, transferring packets inside a data center has been problematic as complex router structures are needed to handle the very large number of IP addresses, as only 256 IP addresses can be present on one subnet. These 256 IP addresses can easily be met by a single blade server chassis. The very large number of addresses or connections, virtual or physical, also creates fundamental routing problems as Ethernet uses a spanning tree protocol (STP) for routing to prevent loops. However, using STP results in many non-optimal routes and difficulty in providing load balancing and multipath benefits. To address these issues Ethernet Fabrics have been developed, primarily based on TRILL, to handle the routing at the layer 2 level and to allow load balancing, multipathing and optimal or shortest path routing. One such Ethernet Fabric is the VCS architecture provided by Brocade Communications Systems, Inc.
If an FCoE to FC gateway is used with an Ethernet Fabric, the single point of connection, the FCoE to FC gateway, remains a problem and to an extent reduces the value of the basic improvements provided by the Ethernet Fabric. Further, an FCoE to FC gateway is to a great extent duplicative of an FCF, which may also be present in an FCoE/FC environment, so the FCoE to FC gateway may provide additional cost.
A problem that has developed in FCoE and has not been resolved despite many attempts, is the handling of peer-to-peer FCoE communication. For various reasons, in an FCoE environment that includes an FC fabric, all packets must travel to the FC fabric. Thus, any FCoE packet intended for another FCoE device on the same Ethernet network must still travel to the FC fabric and then back. Much debate has occurred, but an acceptable problem has not been determined.